By way of general background, scripting languages are programming languages that control software systems, applications and programs. Scripts are often treated as distinct from “programs,” which execute independently from other applications. In addition, scripts can be distinct from the “core code” of an application, which may be written in a different language. Scripts can be written by developers or other programs, in source formats or object formats, which range the gamut in terms of human friendly or machine friendly, or neither. Where accessible to the end user, scripts enable the behavior of an application to be adapted to the user's needs. Scripts can also be interpreted from source code or “semi-compiled” to bytecode, or another machine friendly format, which is interpreted. Scripting languages can also be embedded in an application with which they are associated.
In one programming context, a developer, i.e., a human being, creates text that defines a source code, a compiler translates the language to a machine friendly format for the given platform. In that context, there are a variety of debugging tools and integrated development environments (IDEs) available to the developer for writing bug-free text defining the source code. However, in other programming contexts, applications or the machines themselves can generate code for execution across data stores, involving no human being at code generation time. For instance, an application might generate code automatically to query a certain data store according to dynamic parameters that frequently change and thus are unknown until code generation time. In this and other cases involving machine generated code, the code need not be created or tested in a human friendly “source code” format since a human need not be involved. Accordingly, an efficient, simple and logical technique for generating and testing machine generated code represented directly in machine friendly format is desirable.
In this regard, there are a variety of scenarios in which it is desirable to directly represent code in an intermediate machine friendly format without going through the process of generating source text. For instance, another system, application or program may create the code, and in such case, it can be beneficial to create and store the programming constructs of the code according to such an intermediate format for future reference, or modification, augmentation, referencing, versioning, etc. In this respect, it would be more efficient to be able to “plug” data representing the programmatic constructs as directly generated or pre-stored according to the intermediate format so that many of the compilation steps implicated with source text can be skipped.
By way of further background, relational databases have evolved for the purpose to organize large numbers of records and fields, and have been used for such large scale data collection, and various query languages and other domain specific languages have developed which instruct database management software to retrieve data from a relational database, or a set of distributed databases, on behalf of a querying client or application. Yet, by and large, due to the specific purposes for which such languages were developed and the context in which they were meant to operate, among various domain specific limitations, such languages, in a nutshell, have failed to provide sufficient generality and have elevated the importance of syntactically complex constructs. Moreover, query languages and programs are typically developed in native source code without providing intuitive direct access to intermediate object code surfaces. For instance, transact structured query language (T-SQL) programming constructs tend to be difficult to comprehend even in native programming language syntax.
There have been some prior attempts at direct generation of intermediate object formats without requiring original developer source code. For instance, the Document Object Model (DOM) is a programming interface for hypertext markup language (HTML) and extensible markup language (XML) documents. A DOM defines the way a document can be accessed and manipulated. Using a DOM, a programmer can create a document, navigate its structure, and add, modify, or delete its elements. As a world wide web consortium (W3C) specification, one objective for the DOM has been to provide a standard programming interface that can be used in a wide variety of environments and applications, being designed to be used with any programming language.
An XML parser can be used to load an XML document into the memory of a computer. When the document is loaded, its information can be retrieved and manipulated by accessing the DOM, representing a tree view of the XML document. Without going into great detail, the documentElement is the top-level of the tree, having one or many childNodes that represent the branches of the tree. A Node Interface is used to read and write (or access) the individual elements in the XML node tree. The childNodes property of the documentElement can be accessed to enumerate each individual node. An XML parser having DOM support should provide all the necessary functions to traverse the node tree, access the nodes and their attribute values, insert and delete nodes, and convert the node tree back to XML. Some of the commonly used node types include: Document type, Processing instruction, Element, Attribute and Text.
In this regard, XML DOM is an example of a conventional attempt to allow data intensive applications to be created and analyzed in a machine accessible format via the creation and interpretation of the tree view of the XML document. However, XML DOM is based on an underlying data model and type system that occludes or obscures the target domain, thereby limiting its reach and generality.
Accordingly, when a large amount of data is stored in a database, such as when a set of server computers collect large numbers of records, or transactions, of data over long periods of time, other computers and their applications may sometimes desire access to that data or a targeted subset of that data via one or more scripts. In such case, the other computers can query for the desired data, read or write to the data, update the data, or apply any other processing to the data, via one or more methods of a variety of conventional query languages. The amount of data being voluminous in such circumstances, the applications for consuming the data have become quite data intensive. Thus, being able to directly generate and store programming constructs of a programming language in an intermediate format according to intuitive and general purpose constructs that are not mired in underlying systemic limitations would greatly facilitate the goals around efficient automatic generation of object code.
The above-described background information and deficiencies of current systems are merely intended to provide an overview of some of the background information and problems of conventional systems, and are not intended to be exhaustive. Other problems with conventional systems and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.